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ABSTRACT - We report on a partially implemented interactive computer aided design tool for 
softv.'are engineering. A distinguishing characteristic of our project is its concern for the 
evolutionary character of software systems. Our project draws a distinction between algorithms 
and systems, centering its attention on support for the system designer. Although verification has 
played a large role in recent research, our perspective suggests that the complexity and 
evolutionary nature of softv/are systems requires a number of additional techniques, which are 
described in this paper. 

Thie managing of complexity is a fundamental issue in all engineering disciplines. We identify 
three major techniques used in rriaturo engineering fields which seern applicable to the 
engineering of softv/are systemis: incremental modelling, multiple and almost hierachical 
decomposition, and analysis by inspection. Along these lines we have (i) Constructed a plan 
library to aid in analysis by inspection (the analysis of a program based on identifying standard 
algorithms and methods in it); (ii) Identified a small set of plan building methods which can be 
used to decompose a softv/are system into loosely coupled subsystems; (iii) Developed the 
technique of temporal abstraction v/hich makes it possible to miodel a program from a viev/point 
which clearly separates the actions of generators and consumers of data and (iv) Developed a 
dependency-based reasoning system uniquely suited to incremental and evolutionary program 
analysis. These methods arc substantially language independent and have been applied to 
programs v/ritten in several commonly used languages. 

*This paper v/as adapted from a proposal to the National Science Foundataion. 
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1. The Nature of The Problem 

Large softwai'c systems are expensive to design and implement, and even more expensive to 
maintain. The foilov/ing anecdote is indicalive of the kind of difficulties which are all too typical.^ 
A major cornmorciai firm undertook the development of a large financial softv/are system about 
seven years ago. The project began v/ith the careful developrnenf of a complete design which 
was then implemented. This effort took four or five years, required six full time programmers and 
cost roughly five rciillion dollars. • During the course of the implementation- effort, many of the 
initial desi::;^n features were found to be unsatisfactory. Furthermore, the firm's business practices 
and tl'e applicable government regulations underv/ent numerous revisions as time went by. These 
factors resulted in a series of modifications to. the system v^hich were documented poorly if at alb 
Althoughi the program at present is knov/n to have certain bugs, it has been very useful. In fact it 
is so useful that the firm v/ould like to modify the program for use jn other departments and on 
other computers. Hov/evcr, no one really knows hov/ it v/orks anymore. The current staff of the 
project has no programmer who has been involved v/ith the system for more than eleven months. 
The only compicio documentation is the original design, now six years out of date.. The firm is 
faced v/ith the prospect of redesigning and receding the entire system from the ground up. 

The evolutionary nature of systems is a central feature in the current softv/are crisis. The 
specifications change, the design changes, and, as bugs are discovered, the implementation must 
be chatr^.cd to fix tlicm. One of the driving forces behind this is the. desire for new features. This 
is proriipted by two main factors. First, it is not possible for the designers or the potential users 
of a system to foresee all of the opportunities for the system's use. Second, the environment in 
which the system operates is itself subject to change. New regulations, business practices and 
technology appear and force modifications to the systemi. 

A dominant problem in the design of large softv/are systems is hov/ to manage and limit the 
apparent complexit)' of the situation so that some reasonable solution can be produced. If all of 
the relevant constraints v/ero considered at once in order to try to arrive at a perfect solution in 
the first place, the details v/ould overv/helm human cognitive capacity. A more effective strategy 
is to start with a solution which is reasonably close to being correct, and then to modify it 
repeatedly until a solution is reached v/hich meets the actual needs. Thus there is both an 
internal and an external cause for the evolutionary nature of softv/are. 

Automatic verification attacks the problem of evolution by attempting to eliminate the need 
for change. If a program is verified at the start, then bugs will not surface later and therefore 
the prograivi v/ill not have to be modified in order to fix them. However, automatic verification can 
be at most only part of the solution to the softv/are problem because it does not attack the 
external sources of change such as changing government regulations. A second use for 
verification is in the certification of softv/are systerris. Such facilities are highly desirable but 
they do not eliminate the need for other types of support during the process of developing code 
good enough to v/arrant the effort of certification. 

We suggest that v/hat is needed in addition is a computer aided design tool which can help a 
programmer deal with program evolution from the initial design phase right through the continuing 
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maintenance phase. We imagine a system (such as the Programmer's Apprentice [Hewitt & Smith 
1975; Rich fv Shrobe 1976,78; Waters 1976,78,79]) v;hich can function as a "junior prograrr.rner" 
might. Such a system does not need to be able to certify the correctness of an entire software 
system. Rather, it must provide the designers and coders v/ith relevant inforrriation v/hich helps 
them to better understand the consequences of modifications. The system would be relatively, 
knowlegeable, but not an expert progran-imer itself. It v;ould be able to understand, explain, and 
reason about programs in terms familiar to a programmer. Its main virtue would be its ability to 
select from the vast annotation associated v^ith a sof.tv/are system the small part v/hich is relevant 
to whatever tasK the programmer is currently conducting. We propose to develop the 
fundamental principles behind such systems and to construct a prototype system which meets 
many of these desiderata. 

II. An Idealized Scenario 

In order to indicate the kind of system vye have in rnind, this section presents an imaginary 
scenario shov/ing an expert programmer interacting with a Programmer's Apprentice during the 
design and coding of a hashed associative retrieval system. Natural English dialog is used in the 
example in order to make the presentation more comprehensible. However, natural language 
understanding and generation are beyond the scope of the work proposed here. 

PROGRAMMER: I want to make a hashed associative retrieval system for tree-structured facts. 
Every fact will be stored in each of the buckets hashed to by one of its leaf nodes. I am 
going to start by coding the insert routine. Here is the code: 

(OEFUN INSERT (FACT) ( INSERTl FACT 1)) 
(DEFUN INSERTl (FACT POSITION) 

(COND ((ATOM FACT) ( BUCKET- INSERT FACT (HASH FACT POSITION TABIESIZE))) 
(T (INSERTl (CAR FACT) (* POSITION 2)) 

(INSERTl (CQR FACT) (+. (* POSITION 2) 1))))) 

APPRENTICE: I do not understand this code completely. I see that you are doing a tree-traversal 
over the fact terminated- at atomic nodes, and that you are doing a BUCKET- INSERT for each of 
these terrrtinal nodes. However, I do not understand v/hat.the computation involving POSITION 
is for, nor why hash takes POS.ITION as an argument. The hashing algorithms I know about take 
only tv/o arguments: a key, and a table size, and compute an index smaller than the size. 

PROGF^AMMBIR: In this systerri HASH takes two arguments in addition to the size argument: an atom 
from tlie fact and a number (position) vahich uniquely identifies the position of the aton^ in the 
tree structure of fl.ie fact. Like a standard hash, it computes, an index smaller than the size. 
POSITION makes it. possible to distinguish between different occurences of the same atom in a 
fact. 

APPREr-rnCE: I stiil dO; not completely understand how. INSERT works. How is bucket-insert going 
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f""^: to work? , - ■ ' 

PROGRAMMER: In this design, buckets will be ordered lists of facts. DUCKEI-INSERT will fetch the 

bucket in the hash tcible indexed by its second argument an'd then use the standard ordered 

list ifiGertion al^^ortthm to splice its first argument into the bucket by side-effect., 
APPRENTICE: I understand the design, but there is a mistake. If the new fact needs to be put at 

the \-ery front of the list, then it is not possible to splice it in. 
PROGRAMER: In that situation, BUCKlT- INSERT will just CONS it onto the front of the list. 
APPRENTICE: That will not work either. You want the fact to become' a member of the bucket in 

the liash table, but this wiil not happen in the case v/here it is merely CONSed onto the front. 

The bucket in the table will still be the old list v/hich is the CDR of the newly created list. 
PROGRAMMER: OK, In that situation, DUCKET- INSERT will not only CONS the new fact on, but also 

store the result in the appropriate table entry. 
APPRENTICE: That seems to fix the. problem, however, there is a problem in INSERT. You said that 

the fact itself was to bo put into each of the buckets hashed to. Hov/ever, thev/ay the code 

is written, Vv^iiat is inserted is FACT which is the atom being hashed on, and not the whole fact. 
PROGRAMMER: You are right again. I should make the v/hole fact be an argument to INSERTI, and 

pass it to BUCKET- INSERT. Can you make that change? 
APPRENTICE: Yes, here is v/hat the code looks like nov/. 

^.m^^ (DEFUN INSERT (FACT) (INSERTI FACT 1 FACT)) 

(OEFUN INSERTI (FACT POSITION WHOLE-FACT) 

(COND ((ATOM FACT) ( DUCKET- INSERT WfiOLE-FACT (HASH FACT POSITION TABLESiZE))) 
(T (INSERTI (CAR FACT) (* POSITION 2) WHOLE-FACT) 

(INSERTI (CDR FACT) (+ (* POSITION 2) 1) WHOLE-FACT)))) 

APPRENTICE: There is still a problem, from v/hat I knov/ about this kind of hash table, each fact 
should be in any one bucket at most once. Hov/ever, I cannot prove that duplicates v/ill not 
be inserted. In general, hashing causes collisions and neither INSERTI nor BUCKET-INSERT does 
anything to prevent a fact from getting put in a bucket twice if it hashes to the same index 
twice. 

PROGRAMMER: Ah yes. To fix this, I wilt break INSERT up into two parts: one, called INDEX, v/hich 
• determines tiie set (as opposed to the rnulti-set) of indices associated with a fact, and the 
other (still called INSERT) v/hich v/ill cai! DUCKET-INSERT in order to insert the fact into the 
corresponding buckets. [And so the scenerio continues ,..] 

This scenario illustrates several of the facilities the type of systerri v/e have inrnind must 
provide. First, it must interact v/ith the programmer during the design phase checking that the 
design is coherent and achieves its stated goals. Second it must record a representation of the 
logical structure underlying the design so that this may be used to detect bugs and guide 
evolutionary changes. Third, the apprentice must be able to recognize common design patterns 
within the code and to explain these in familiar, high level terms. It must also use these to 
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structure its undcrc-.landing of the design in ways which make it convenient tp, rea^^pn a,bout the 
program and about proposed modifications to it. 

III. Types of Programs— ^ Algorithms versus Systems 

It is important to distinguish between tv/o quite different kinds of programs: algorithms and* 
systems. Each kind of program is important to software enginpering. Hov/ever, they present quite 
different demands and requirements. We argue that current, program verification techniques are 
most useliil and necessary for algorithms. The thrust of pur work is directed tpv/ards the 
problems inherent in the design of systems. 

Algorithms and systerrts differ along two primary dimensions: the character of th^ir 
specifications, and the sources of their complexity. In general, an ajgorithm is a relatively short 
program which is precisely and concisely specified. For example, the Knuth-Morrls-Pratt and the 
Boyer-Moore string matching algorithms each require roughly 100 lines of code but have a very 
short precise specification: the ansv/er returned is the positipn oj the first substring of the text 
which matches the input pattern. An algorithm is built to satisfy a precisely stated specification 
v/hich has genera! utility. Therefore it is reasonable to expect that this specification will not have 
to evolve in the future. As a result, the effort required to actually verify the program can reap 
benefits far into the future. For example, Euclid's algorithm has survived unchanged for thousands 
of years. 

In cor^trast to ajgorithrns, softv/are systems are large programs v/ith specifications and other 
related documentation much larger than their code. More important, v/hen specifying a system it 
is often inipossible to state precisely what is to.be done. Typically some claims arernade about 
vyhat must happen and others describe desirable but less crucial behavior. In any event these 
specifications often change, and the system is forced to evolve to meet the new criteria. The 
incompleteness ^nd imprecision of "the specifications for systems makes rigorous verification 
difficult, and the impermanence of the specifications red^uces the rewards of producing such a 
verification, ■ 

The complexity of a typical algorithm stems primarily from clever underlying logic (often due 
to obscure optimizations) ^^Mch requires proof in order to b^ believed. The intricacies of the 
string matching programs mentioned above v^QuJd, lead one tp dpu.bt vvhethcr they v/orked unless a 
rigorous proof were presented. If algorithms were subject to evolutionary change, this intricacy 
would be a significant iiabiiity. 

In contrast, a system is usually made up of a large number pf relatively small modules, each 
of v/iiich . involves fairly routine code. An experienced programmer can easily understand and 
trust the local operation of sucii a system by recognizi'ng standard patterns in the code. In other 
words, recognition can largely replace formal proof at this level. The complexity of softv/are 
systems arises primarily from the number of interactions betv/een modules. These are v/hat rn^ke 
it difficuH to assess the effect of a proposed change to the system. Systems tend to reach a 
point v/iiere the number of. these interactions overv/heims unaided human abilities to manage them. 
■From that point on, modifications becpnie increasingly bug-prone. 
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^*^, These di^/.tinctiono between algorithms and systems point to the need for different kinds of ' 

desi'-^.n pidb in tluo tv/o dorru'Mn'^, Tho designer • of e'sigdrithms needs, proof checkers, theorem 
pro\^ers, and verification systems. V\fh\\e these serve a useful role for the system designer as 
well, they arc not his bread and butter. Instead he needs tools v^hich can help him evolve designs 
which satisfy evolving criteria. Rather than a tool for, proving convoluted programs correct, a 
system designer needs a tool v^hich can structure and rerriernber the straightforvyard arguments 
for parts of large but routine programis so that the proofs can be used to guide an analysis of the 
effects of niodifications. , . . • ' 

IV. Problem Solving Theories 

Three key ideas in current Artificial Intelligence theories of problerh solving are: problem 
solving by recognition of the form of the answer, using planning in a simplified "abstraction" space 
in order to guide the problem solving process, and using debugging in order to transform an 
alr^iost right solution into a correct solution. 

One hallmark of an expert problem solver is the ability to recognize the form of the solution,, 
to a problem based only on a fov/ high level features of .the problem description. This reduces 
the initk^lly unmanageable search in a very large solution space to an exploration of possibilities 
within a much srr;a!tcr space. In electrical engineering, the form of a solution might be a particular 
circuit tooolopy with certain components undetermined. In programiming, the form of a solution 
^ '' rnighi be a particular control strategy with unspecified primitive actions. This problem solving 

idea finds its antecedents in the Means-Ends analysis of [Nev/eli, et. al., 1959] and in MinsKy's 
notion of "islands" [Minsky, 1961] and v^as later formalized in the Planner programming language 
[Hev/itt 1972] and its descendants Conniver [McDermott fv Sussman 1974] and QA4 
[Rulifson ot. aL 1973] where the form of the solution is called a plan. 

In sufficiently complex situations, a second paradigm called planning in an abstraction space, 
is^also used. An abstraction space is a model of the real world in which' some important details 
are intentionally omitted. Recognition of the form of the answer is first attempted in an 
abstraction space. If a plan is successfully formiulated in the abstraction space, then it is modified 
to vvork in increasing more realistic spaces until a satisfactory solution is found. This problem 
solving paradigm was embodied in the ABSTRIPS program [Sacerdoti 1973]. 

Both the planning paradigm and the abstract modelling paradigm point to debugging as an 
unavoiciable part of designing complex systems. The role of debugging in problerrj solving has 
been in\'cstigated by Sussman in his HACKER program [Sussman 1973]. When a plan is initially 
produced by recognising the form of the answer in an abstraction space, the plan has associated 
with it an explanation of how it achieves its goals. However this "proof of correctness" is likely to 
be faulty because it depends on assumptions in the model v/hich contradict facts in the real v/orld. 
The almost-right plan is refined by developing a more realistic model of the situation and then 
using the old "proof of correctness" to guide the debugging process. 
/^**^. \l\Jc believe those ideas constitute the best understanding to date of how people manage the 

complexity of planning and problem solving in complex domiains and therefore these ideas should 
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form the conceptual basis for developing cornputer aids for software engineering. 

V. What Do En,q;ineers Do? 

!n this section we discuss some specific techniques vyhich have proved effective in more 
mature engineering domains such as electrical and fnechanical engineorlhg and which we think can 
be fruitfully applied \o softv/are engineering. 

One might think that engineering is mainly concerned with the optimisation of numerical 
paramieters vyithin physical systems and that computer science therefore has little to gain from the 
study of methodologies used in engineering. However, although engineers are at times concerned 
with numerical optimization, it is not their main activity. The dominant problemi in engineering is 
the managemient of complexity during' design and analysis. This can be seen in the following quote 
from a standard electrical engineering text [Bose <!i' Stevens 55]. 

A piiysicat problem is ne^er analyzed exactly. This is a consequence both of our 
inability to describe a physical situation completely and of the increasing comtplexity of 
the analysis as greater accuracy is demanded. A problem that involves events in the 
real v/orld is nivyays approached by making simplifying assumptions that hold only 
approxin'iately, thereby forming a model of the events under study. The probiemt then 
reduces to that of analyzing the model. If the assumptions by means of v/hich the 
physical situation v/as reduced to the model are reasonable, then our analysis should 
produce results that correspond to observed events, and the same type of analysis 
. should be useful in predicting the behavior for other similar physical situations. 

Thus, as the problem solving theories predict, engineers use abstract models to manage the 
complexity of their domains. Tv/o particular abstraction techniques Vi'hich engineers use are: the 
construction of multiple models each of v/hich is accui'ate Only under a restricted set of operating 
condition:,, and the decomposition of complex Systems into several possibly overlapping hierachical 
Organizations. Both of these techniques omit details which are not relevant to the task a\ hand. 
An example of the first technique is a linear model of a transistor u^hich describes its behavior 
accurately only when it is operating v/ithin a certain range of frequencies and pov/er. Sometimes 
several different models v/ill be used v/hich together form a good overall description, as for 
example ihe DC and frequency domain models for a circuit. 

Engineers use decomposition to break up a large system into a (possibly overlapping) 
hierarchy of subsystems. Each subsystem is given a simple description v/hich includes only those 
aspects of its behavior v/hich are relevant to other subsystems. The v/hole artifact is then: 
regarded as a loosely coupled network in which the behavior of the whole system rnay be 
deduced from the descriptions of the subsyslerns.. The simplest kind of decomposition involves 
only a sirv-jje non-overlapping hierarchy. Hov/ever, sometimes a single component may be logically 
part of tv/o or more different subsystems, and sometimes several different decompositions of a 
system are necessary in order to, derive convenient descriptions for all of its behavior. 
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Decomposition is already a cotrimon technique in computer science. The use of subroutines 
a^ p!(KC'cliiral cibsti'cK'tions described by their input-output behavior is v/elt established. Data 
abstraction techtiiques allow a another Kind of deconiposition. Typicalh/j these techniques are 
crnbodiod in the features of a pro[^,ran-rriing language such as CLU [Liskov et. al. 1977] or ALPHARD 
[Wulf 1974]. While v^e recognize the irnprovernent such languages offer over, earlier languages, 
we do riot bolJDve that they solve the whole probiern. Convenient analysis frequently requires 
multiple decompositions of a single system, but unfortunately prograrnrning languages require that 
a system be represented by a single decomposition constained by the way in which the program 
is intended to execute. • . 

The idea of problem solving by recognizing the form of the solution appears in engineering 
both in design and analysis. Evidence of, this is the development of a vocabulary of useful miacro 
structures v.'hich constitute the abstract forms of. the solutions for broad classes of problems. In 
ar.y engineering discipline, the basic units of design arc a set of primitives (such as transistors, 
resistors, etc, or CONS, CAR, CDR, etc.) and rules for their legitimate combination. These generate an 
infinite number of legitimate combinations only some of v/hich zre useful. The rnacro structures in 
the intermediate vocabulary serve as stepping stones which make it cognitively feasible to derive 
the useful combinations from the primitives. 

IVe do not intend to imply that there is a unique set of universally useful intermediate 
constructs but rather that it is always fruitful to look for them. Different domains employ quite 
ciifferent engineering vocabularies. Once an intermediate vocabulary is developed it expands the 
cogniti\/C' range of those practitioners who learn the vocabulary. As a result, they ^re capable of 
conceiving of yet more complex combinations, which leads to a higher level engineering 
vocabulary. For example, in electrical engineering one first learns to engineer useful netv/orks 
using intermediale constructs such as voltage dividers. In order to combine these into more 
complex artifacts, one learns a higher level vocabulary including notions such as oscillators and 
amplifiers. 

In programming the connection betv/een the microscopic and the macroscopic is also 
mediated by an intermediate engineering vocabulary. If one is to v;ork with a particular 
programiming language one must knov/ v»'hat its primitives do. However, program analysis which 
exclusively concentrates on the axiomatic description of program primitives is inadequate to deal 
v/ith the complexity of real v/orld programs. Indeed most of programi understanding happens at a 
macro level wliici"! is more appropriate to the task at hand. It is at this level that one learns and 
remembers the useful patterns of doing things. For example, it is more fruitful to think about two 
linked lists, and about "splicing" as a kind of operation on these higher level objects, than to think 
of computer memory as a large collection of cells and about changing pointers in particular cells. 
In this way, we are rriuch. more likely to arrive at a computationally feasible and easily 
understandable description of the behavior of a program. One of our research goals is to create a 
catalog of intermediate engineering vocabulary for programming. 
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VI. Plans and Teleology 

An engineer must have a representational system v/tthin which it is possible to utilize and 
coordinate information derived through the techniques described above. In most engineering 
disciplines there is a notion of the "design plan" v/hich forms a skeleton around v/hich all of this 
information is arranged. Of all the issues discussed so far, the design plan is the one least v/elT 
addressed i)y other current v/ork in computer science. Because the use of plans in softv/are 
engineering is a central theme in our approach, we begin the presentation of our current work 
with an explanation of v/hat a plan, is and hov,/ it is represented. 

In traditional engineering or software engineering, the behavior of a device or part of a 
device can be described. in tv/o ways. Some properties of a device are independent of its context 
of use. Tiiosc properties constitute the intrinsic description of the device. For example, a 
capacitor can be described by the relation I{t) - C dv(t)/dt. The LISP function APPEND can be 
described intrinsically by its input-output bc^havior of returning the concatenation of its 
argumients. Intrinsic descriptions correspond to specifications in the literature of software 
engineering. 

A device may also be described by its role in the plan for a larger mechanism. This is its 
extrinsic description. For example, a particular capacitor may -be described as a coupling 
capacitor, a bypass capacitor, or a tuning capacitor, depending upon its purpose in the circuit. 
Similarly, APPEND may be used to produce the union of tvvo disjoint sets represented as lists, or to 
attach a suffix to a root word represented as lists of characters. The abstract form of an ansv/er 
retrieved in tlie process of engineering design is a plan in v/hich each part is specified only by its 
extrinsic properties. Synthesis involves filling each role in the plan with a part whose intrinsic 
description satisfies the given extrinsic description. ' . 

A single part may have several extrinsic descriptions corresponding to multiple needs that it 
satisfies in the larger rrsechanism. For example, a screw in a camera' may fasten tv/o plates 
together and also provide a fulcrum about which to pivot a lever. There may also be several 
plans for a given device, describing its structure in different dimensions. In this situation, ^ part 
may fill several different roles in several different plans. For §%^mp\e, in a radio-frequency 
amplifier an -inductor may be both part of a resonant circuit in the frequency domain plan and part 
of the bias netv/ork of a transistor in the^ DC plan. 

The essence of understanding a mechanism is knov/ing the purposes 6f each part. This 
involves building a description of the rnechanism which matches each part v/ith its roles In the 
appropriate plans. Each role in each plan must be filled by some part of the mechanisrr* and the 
intrii)S}c properties of tliat part must .satisfy the extrinsic properties of its roles. 

The utility of this Kind of understanding is that it factors knowledge. A given plan fragment 
ean appear as part of the plahs.fdr many different devices. ' Therefore understanding the logical 
structure of a plan fragment (which may. be very difficult) need only happen once. Any properties 
of the pli?n fragriient v/iiich can be proven, are known to hold wherever the plan is used. These 
plan fragments arc the intermediate vocabulary items discussed in the last section. 
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^^"" V}!. Represenfin^ Plans 

In order to look at pro[i;rams from the viewpoint of a design plan, v.'e have devised a 
forrnaliGiri called pf^n dip.gr^ms v/hich can be ur.ed to describe both abstract program patterns and 
,, concrolc programs. The basic cnlities in the plan diagram formalism are segments (input/output 
abstractions) d^^(\ data Objects. The formialism supports hierarchical description ■ by al!ov/ing 
scginents Vv'ithin segments (subsegmonts) and objects v/ithin objects (s'ubobjects). The most basic 
relationship betv/een these entities is the application of a segment to a set of input objects, 
yielding a set of output "objects. The formalism includes four other primitive relationships: data 
flov/, control flov/, control splitting, and control joining. It is a straightforward matter to give the 
proof rules for the forrrialismi, as has been done in [Rich 8^ Shrobe 1975; Shrobe 1978]. 

In order to analyze prograrris v/ritten in a particular programming language one needs to 
have definitions for the language's primitives. Vv/e divide programming language primitives into 
two categories: connective tissue primitives such as IF-THEN-EISE, while, variables, argument 
passing, etc. Vv-Tiich are concerned solely v/ith irnplemienting data and .control flow, and actions such 
■ as arithmetic operations, CONS, CAR, CDR, etc. The first category is described by a transiational 
sernatics in ^A'hlch the primitive is mapped into the appropriate pattern of control flow and data 
flov/ links. Actions arc represented as segments specified by pre-conditions and post-conditions. 
We. have already constructed such "language semantics for LISP [Rich & Shrobe 1975] and 
_^ FORTRAM [Waters 1976,73] and have implcmohted systems v/hich translate programs v/ritten in 

these languages into the plan diagram formalism. The translation process removes miany of the 
surface features of the particular programirriing language, creating a flow graph v/hich gives 
greater insight into the underlying logical structure. 

Each sogmerit in a plan is constrained either by its spec-type or by its plan-type. The spec- 
type of a segment is a formal statement of the relationships v/hich are expected to hold for the 
Input objects prior to its execution (pre-conditions) and the conditions v/hich are guaranteed to 
hold immediately follov/ing execution of the segment (post-conditions). These conditions are 
expressed in a variant of the Situational Calculus of [McCarthy & Hayes 1959]. Each segment has 
associated v/ith it an input situation and an ouput situation which are representations for the state 
of affairs ori entry to and on exit from the segment. 

The plan-type of a segment constrains what plan (i.e. v/hat subsegments, and data and 
control flov/) is used to implement' the behavior specified for the segment by its spec-type. In the 
case of recursive programs and loops (which are represented as singly recursive programs) the 
plan-type for sorrie subsegrnent v/iil be the.samie as the plan-type for the overall segmient. 

Data objects are similarly described by object-type and plan-type. Object-types are a kind 
of data abstraction decomiposing a data object into subobjects satisfying a specified set of 
contraints. Implementation rules constrain the plan-type of segments according to the plan-types 
of their input and output objects. The coordination of procedural and data abstraction is an 
important and novel feature of our represention system. 
./*^. The plan diagram formalism is intended to facilitate our goal of cataloging the comimon and 

useful techniques of prograrriming. The spec-types and object-types are arranged in a tangled 
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hierarchy with move specific types inheriting descriptions from their super-types. For example, 
the LISP-siylo fissociation-list is a specialisation of both the object-type tinked-list and the 
object-type associative-data-slruclure. 

In order to represent the logical relationships in a plan, a plan diagram is augmented v/ith a 
network of purpose links v/hich summarize how the parts of a program interact in order to 
produce the behavior of the whole program. These links make it possible for a design aid system 
to explain how a program works, and reason about the potential effects of a modification. There 
are two basic ways in which the appropriate purpose links can be developed for a plan. They can 
be copied by reference to a stored plan in a catalog of programming knowlege (see section X), or 
they can be derived by reasoning directly about the plan itself. 

Symbolic execution [Hewitt & Smith 1975; Hantlcr S^ King 1976; Rich & Shrobe 1976,78] of 
plan diciorams [Slirobe 1978] can be used to reason about programs and to create the appropriate 
purpose links. Symbolic execution of a plan operates as follows. A set of anonyrrious objects 
(skolenv constants) is created, one object for each input to the outermost segment. Data objects 
are propagated along the data flow links leading to the initial subsegment, A subsegment is 
marked ready whenever all of its incoming data objects are present. The symbolic execution of 
the subsegment is tiien begun. . This is done in one of two v;ays depending on v/hether it has a 
spec-type or plan-type. 

If the subsegment. is described by a plan-type its symbolic execution proceeds recursively. 
Its inputs are propagated along its data flov/ links to its subsegments and these are then executed 
as they b^ecome ready. If a subsegment is described only by a spec-type, it is first necessary to 
demonstrate that the subsegrnent's pre-conditions are satisfied. If this demonstration is 
succossful, then the subsegment is applicable. Anonymous objects are created to represent the 
outputs of the subsegment and the posl-conditions of the subsegment are asserted to hold iri its 
output situation. The output objects are then propagated along data flov/ links to other 
subsegments which then become candidates for symbolic execution. Once all the subsegments 
iiave been executed, one then demonstrates that the assertions of the supersegmient hold in its 
output situation. If this is successful, then the plan has been shown to achieve its desired effect. 

Tlie iogical arguments v/hich are constructed during this process are surnfrieiri2:ed into 
purpose links which capture the underlying telcological structure of the plan. There are tv/o basic 
kinds of purpose links: prerequisite links, v/hich shov/ how the pre-conditions of a subsegment 
are satisfied by the interaction of the pre-conditions and post-conditions of other subsegments, 
and achieve links, which record hov/ the pre-conditions and post-conditions of the various 
subscgrrionts interact to achieve the post-conditions of their supersegment. These are simitar to 
the proof surnmarizations used in [Moriconi 1977]. 

A p^in may be thought of 'as an abstract program coupled v/ith a logical analysis. Hov/ever, it 
is important to note that this logical analysis need not necessarily be a "proof" in the sense of a ' 
guarantee of correctness. Our reasoning system [Shrobe 1978] is capable of conducting logical 
arguments v/hich range from informal to rigorous. In miany cases the plan for a program will only 
contain a "corrimon sense" or engineering type analysis v/hich is inadequate to guarantee 
correctness under all conditions, but which is good enough for purposes of explaining its 
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teleologicai structure. When it is necessary, our reasoning system can be asked to carry out the 
vorificeitiOM of certain modules v/ith full rigor, f-lov/ever/in this part of the process, v^c have made 
no .id'^ancf''-^ over other verification systems. Our main goal is not the proof of correctness of 
large softv/are syslerns, but rather an engineering oriented explanation and bookkeeping facility 
of sorne sophistication v^'hich v./i!l make it easier for a software engineer to modify a system while 
convincing himself that it does what he intends. 

Vlll. Temporal Abstraction 

Temporal abstraction [Shrobe 1978; V\/aters 1978] is a modelling technique which makes it 
more convertient to analyze the logical structure of recursive plans. In a temiporal rnodel, the time 
behavior of' a pro;:;ram is unfolded so that the occurrences of the subsegments can be regrouped 
to make common programiming fragments more easily identifiable. 

For example, consider the foliov^ing recursive Lisp prograrri which builds a list of the terminal 
nodes of a binary tree. 

(DEFUN DEPTH-FIRST-FRINGE (TREE) 

(PROG (FRINGE) ( DEPTH-F IRST-FRINGEl TREE) (RETURN FRINGE))) 
(DEFUN DEPTH-FIRST-FRINGEl (NODE) 

(COND ((ATOM NODE) (SETO FRINGE (CONS NODE FRINGE))) 
(T (DEPTH-FIRST-FRINGEl (CDR NODE)) 
(DEPTH-FIRST-FRINGEl (CAR NODE))))) 
We can analyze this program as the composition of three fragments: 

(i) a tree-traversal segment, implemented by the depth-first plan, which 
enumerates the nodes of the tree, 

(DEFUN DEPTH-FIRST-FRINGEl (NODE) 
(COND ((ATOM NODE) ... 

(T (DEPTH-FIRST-FRINGEl (CDR NODE)) 
(DEPTH-FIRST-FRINGEl (CAR NODE))))) 
(ii) a filter segment which selects out the terminal nodes for further processing, 

(COND ((ATOM NODE) ... NODE ...) 
(iii) and an accumiuiation segment v/hich builds a list of the selected nodes. 
(PROG (FRINGE) ... 

... (SE1Q FRINGE (CONS NODE FRINGE)) 
Tills intuitive decomposition into a generator, a filter and an accumulator has considerable 
conceptual pov.'er. This section will sketch the formalization of this decomposition used in the 
apprentice system. The method is be based on analyzing the history of applications during the 
course of an er^tire computation and grouping these into occurences of segments of like type. 

.Given a set of inputs to a plan diagram, the rules for symbolic evaluation unambiguously 
specify v/iiich of its sub-segmients v;ili be applied and to which arguments. Each such application 
is described by an input situation, a set of bindings of data objects v/ith the input names of the 
sub"segrrtent, an output situation, and a set of bindings for the outputs. The data and control flow 
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links intpose o natural partial order on the applications corresponding to their order of execution. 
A graphical representation of the plan diagram for Depth-First-Fringe is shown in Figure 1. 
(Cross-hatched lines represent flow of control, solid lines represent data flow. A box v/ith two 
sections at its base is a test, one with tv/o sections at its top is a Join. A curiy line indicates that 
the inner segment is a recursive instance of the outer segment. Temporal abstraction makes it 
possible to rnodei this program with the plan diagram of figure 2. 

Temporal analysis begins with the notion of an occurance set of a particular plan (or spec) 
type. Given an application of a plan diagram the "occurance set of typel" consists of all 
applications v/iti^in the plan diagram v/hose type is typel. In the Depth-First-Fringe program 
above there are three occurance sets of interest: (1) The occurance set of type Depth-First- 
Fringel, (ii) The occurance set of type "Atom Test" and (iii) The occurance set of type "Cons". 
These correspond to the three fragments of code identified at the beginning of this section. 
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Figure It'Plan for Depth-First-Fringe. Figure 2: Temporal rriodel of Depth-Ftrst-Fringe. 



• Next we consider the sets of inputs and outputs of t-he segments within an occurance set. 
An occur fjnce set consists of applications of segments of a cori-jmon plan (or spec) type; the plan 
diagrairi for this type provides a set of local names for these segments' inputs and outputs. For 
example, the plat^ diagram for Dcpth-First-Fringol contains the input name "Node". It is useful to 
tiiink of tl'ie set of objects v/hich.are bound to this name in any application of a segment of type 
Depth-First-Fringol. Given an occurance set and a local. name, v/e define a temporal collection to 
be a set of pairs consisting of (1) data objects which are bound to the selected local name and (2) 
tine application in v/hich they are bound. The temporal collection is partially ordered by the 
natural .order of the applications. If Depth-First-Fringe is applied to the data 'object Tree-i then 
the temporal collection of Node inputs to segments of type Depth-First-Fringel will consist of 
pairs containing all the nodes of Tree-1'in depth first order. This is shov/n diagramatically in 
Picture 3. ■ . " 
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For every rnember of the occurance set of type Depth-First.-Fringel there is a data flov/ link 

.to nn occurance of type Atom-Test. Such a collection of identical data flow liriks ib called a data 

flow bundle. The collection of objects which flow along these links form two temporal' collections, 

one at tiic segments on the initiatin^;^ side of the data flov/ links and the second at the terrninating 

side. . 

: IJciinf; these concepts to examine the program. Dep.th-First-Fringe makes .it possible to 
decompose tiie program into units which can be analyzed by inspection. The occurance set of 
type Depth-First-Fringei is a Binary Tree Travervali each segment in the set either has an 
atomic r.'ode input, or it has data flow links to a CAR and a CDR segment which in turn have data 
flovy links to other segments of type Depth-First-Fringel. As already mentioned the temporal 
collection of Node inputs to rnernbers of this occurance set contains all the Nodes of the tree. 
There is a data flov/ bundle from this occurance set to the occurance set of iype Atom Test. The 
latter set is a filler,- an occurance set of identical test segments. Its input temipora! collection 
contains all tlie nodes' of the tree. Its output temipora! collection is the sub-collection consisting of 
all Ncj.des which satisfy tiic' Atomi Test. Those arc the termiinal nodes. There is a data flov/ bundle 
carrying tliis subset from the. Atomt-Test occurance set to the Cons occurance set. This last set is 
, an accumulation; each segment in it takes one input from a previous Cons segment. The second 
input to each of tliese segments flows to it fromi a memiber of the Atom-Test occurance set. This 
decomposition is shown diagramiatically in Figure 3. 
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Figure 3: Temiporal decomposition of Depth-First-Fringe. 
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We now build a model of Depth-First-Fringe. V\/e miodel each occurance set as a single; 
segment; each data flow bundle as a single data flow link and each temporal collection as a single' 
data object. The resulting miodel consists of only three segrrients Binary Tree Traversal, Filter, 
and Accumulation. The data flow links in the model form a simple pattern, each segment taking a 
single input from its predecessor. From this viewpoint the program appears. is seen as a simple 
corciposition. Notice that the temporal rrtodel suggests the following clear and concise explanation 
of Depth-First-Fringe: "The program consists of three steps, first it generates the nodes of the 
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tree, second it selects out those nodes v/hich are terminals, and third it builds a list of these 
nodes." This model is shown in figure 2. 

IX. Plan Building Methods 

The entire process of analyzing a program would be made much easier if it v/ere posGible to 
decide how to break a program into parts before determining what any of the parts do. One 
approach to this segmentation problem is taken by Waters [1978] who has developed and 
irnpiemented a system v/hich discovers the logical segmentation of a large body of common 
programs. His analysis is based solely on recognizing topological patterns of data flow and control 
flo^v v/ithout regard for the specifications of the various operations involved. These patterns are 
called plan building methods {PBMs)^ because they can be thought of as instructions for hov/ to 
combine plans together to form more complex plans. 

The simplest PBMs .correspond to the standard structured programming notions of 
conjunction, composition, and conditional. More complex PBMs decompose recursive plans by 
making use of temporal abstraction and trajectories. 

Tiie recursive PBMs make it possible to construct a temporal model for a recursive program 
in v/hich its structure is revealed as the composition of standard segments v/hich can be 
understood in isolation fromi each other. Three basic recursive PBMs produce three types of 
standard recursive segments: ter ruinations, filters, and augmentations. 

A filter segment is one v/hich tests a temporal sequence of values and selects out a 
consistently ordered subset to be acted on by other segments. 

A termination segment is one which tests some temporal sequence of values of values and 
can cause the termination of the recursive program as a v/hole. (The atom test in the DEPTH-FIRST- 
FRINGE program doubled as both a filter and a termiination segment). As such, it determines the 
length of all the trajectories in the temporal decomposition of the given recursive plan, but does 
not affect what is; computed in these trajectories. 

All other segments are referred to as augmentations, Augmtentations t^ke in trajectories of 
values and perform calculations in order to create additional trajectories of values. Typically, an 
augmentc^tion will have feedback of dat.a flov/ to itself, so that it can utilize past values in its 
cOfTiputations. The accumulation segments in Section VIII are augnientations. 

The analysis of a recursive plan using PBMs turns out tobe straightforward.. The basic idea 
is that a part of the program affects the rest of the program only if it either has data. flow to 
some other part of the program, or controls v/hcn some other part of the program v/ilt be 
executed, Decotrfposition is achieved by locating segments of the plan v/hich do not affect 
anything in thie rest of the plan. -(Note, that this has to be, v/eakened slightly in the case of 
terminations.) When such a segmiont is found,' it is pulled out of the plan and the process is 
repeated until nothing else can be pulled out. The segmients that are pulled out are connected 
together temporally by trajectories' as explained in Section VIII. Thus, Waters' analysis provides 
one means of decomposing systems into loosely coupled sub-systems. 

An expertfnent was performed in order to determine v/hether or not the particular PBMs 
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cho^--en had a v/ide range of applicability. A random $arnple of 20% of the programs in the IBM 
Sriontific Subroutine Packaj^e were analyzed in terms of PBWs by hand. AH of the programs 
turned out to be analyzable in terms of the the PBMS. More importantly, noariy 90% of. the time, 
the annlysis broke the programs up into segments v/hich v/ere so simple that it v/as trivial to 
understand what the segments themselves v/ere doing. 

X. A Library of Plans and Analysis by Inspection 

As WD have seen, one of the major goals of temporal abstraction and PBM decomposition is 
to facilitate analysis by inspection. The basic idea is to analyze a given program by recognizing 
patterns of segments in the deconvposcd plan as instances of commonly Known correct plans 
stored in a library. Work such as [Barstow 1977] suggests that it is possible to catalog 
substantial portions of programming knowledge in a reasonably concise formalism. We have begun 
a similar cataloging effort [Rich forthcoming] using the plan formiaiism, v/hich we believe v/ill have 
several advantages. Most in'tportant among these is the fact that our plan library is not biased 
towards eitiier synthesis or analysis, but attempts to capture the knov/ledge underlying both. 

The plan library is a formalization of the intermediate vocabulary (Section IV) of softv/are 
engineering. It includes standard plans (patterns of data flov/ and control flov/ betv/een specified 
subsegrnents) for implementing common input-output specifications, and standard plans (sets of 
objects v/ith constraints betv/een them) for implementing common data abstractions. Plans in the 
library are pre-proven, i.e. they have attached to them explanations that can be combined with 
■the explanations of other plans in order to arrive at a complete explanation of hov/ a given 
program v/orks. 

Examples of plans that v/e have formalized are: (data plans) implementing a set as a list, 
imiplementing a binary relation as a hash table, implementing a stack as a sequence plus a cell, 
implementing a tree using pairs; (procedural plans) list traversal, tree traversal, filtering, linear 
search, sequential accumulation. Many of these plans fit into a specialization hierarchy v/hich aids 
in finding the right plan during analysis or synthesis. For example, binary tree traversal is a 
specialization of tree traversal, and hash tables are a specialization of associative data structure. 
One of our research goals is to extend this catalog to include even higher level concepts, such as 
interpreter, data-based system, etc. 

Recognition of the PBMs v/as so successful because there were a smalt numiber of them and 
they v/ere all very different from each other. Recognizing instances of library plans in the plan 
for a given program v/ill be miore difficult because there are many plans in the library and they 
tend to have some features in common. Our first approach v/ill be to see how far v/e can get 
continuing the bottom-up style of recognition from PBM analysis into recognition- of the 
intermediate vocabulary. However, v/e will certainly have to eventually develop some top-down 
recogfiitioii strategies to m;ike it possible to recognize the very high level concepts. 
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XI. Dependency Directed Reasoning and Program Modification 

A prototype dependency directed reasoning <;ystern [Shrobe 1978] has been irripiernented in 
the AMORD programming language [de Kleer et. ai. 1977]„ In a dependency directed system ^very 
nevy assertion entered into the data base is accompanied by a justification stating which other 
assertions form the logical support for the new one. The justification itself is an object which the 
system can inspect and manipulate. 

Assertions in the reasoning system have two states: in or out. An in assertion is one v/hich 
is beiieved. An out assertion is one not currently believed. A special mipdule called the Truth 
Maintaincnce System (TMS) [Doyle 1978] is responsible for guaranteeing that alf assertions with 
valid reasons to be believed are in and all assertions v/hich lack valid justifications are out. This 
facility is particularly flexible because an assertion can be justified by the lack of valid support 
for some other assertion. Technically this means that the assertion Fl may have a justification 
which depends on the oufhess of some other assertion F2. This amounts to saying that as long as 
there is no reason to believe F2 one should assume Fl. If reason to believe F2 is ever discovered, 
the TMS v;ill automatically bring F2 in and Fi out. Addition of ar\ assertion (F2) can cause another 
assertion (Fl) to become invalid. Logics with this property are called non-monotontc 
[Doyle 1978]. The semantics of such logics is discussed in [McDermott & Doyle 197S]. 

We see two key applications for dependency directed reasoning in software engineering: 
hypothetical reasoning during theorem proving and analysis of program modifications. For 
example, [Shrobe 1978] describes the use of dependency directed reasoning to reason about 
side-effects by first assuming that the degree of sharing betv/een complex data structures is 
limited. Various desired properties of the program are then proven under this simplifying 
assumption. Sometimies such a cursory analysis is all that is appropriate. However, when a more 
careful exploration is desired, -the assumption can be removed and replaced by a more cautious 
assumption or by no assumption at all. In many cases, some of the important properties of the 
program do not depend on the assumiption and remain /a However, if some property does in fact 
depend on the assumption it.v/ill.go out indicating that the original proof is no longer valid under 
the conditions of sharing. A more complicated proof of that proper\y can then be attem.pted. 

A dependency based reasoning system also makes it possible for incremental changes in a 
program to necessitate only increrriental changes in the analysis of the program. Suppose, for 
example, that a programmer decides to change the representation of some data object from arrays 
to binary trees. He would' then replace all instances of loops enumerating the elements of the 
array witli tree traversals enumerating the nodes of the tree. Although the new code might bear 
little superficial resemblance to the old code, [Shrobe 1978] shov/s that dependencies irjake it 
possible Iq handle this change by an incremental re-analysis of the program rather than by a new 
analysis from scratch. 

[Doyle 1978] shows how dependencies can be used to achieve many of the control 
disciplines v.'hich have been used in automated theorem proving systems. Most important among 
these is dependency directed i:>acktr aching in which a contradiction is rerrtoved from the system 
by first identifying those assumptions which lead through a chain of dependencies to the 
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a^sutviptions. cannot be in at the same time. The reasoning system can then select an assumption 
to reject. [Stallrnan & Sussman 1977] show how this technique reduces comibinatorial explosions 
in an electrical circuit analysis system. [Shrobe 1979] shov/s that dependencies are adequate to 
achieve the effect of the contexts of QA4 [Rulifson et.. a!. 1973] and Conniver 
[McDerrnott & Sussman 197^] while avoiding some of their problems. — 

Xtl. Conclusion 

We intend to furhter develop the modules v/e now have in order to irnplornent and 
experiment v.'ith a computer system that can understand and reason about programs using the 
rnetliods and representations presented above. This system should be .the prototype for an 
interactive programming environment in which both the computer and the humian programmer 
cooperate to produce software more quickly and reliably than either could do working alone. In 
this environment tlie programmer v/iil treat the computer as if it v/ere a colleague, explaining and 
developing the program design interactively. The computer will play a passive rolej its strength 
is not design but rather careful bookkeeping and criticism. 

Ours is only one of many approaches towards alleviating the currrent soft\vare crisis. High 
level languages, structured programming, verification, and automiatic programming also make claims 
^«^ to bein^ part of the solution. Indeed, a pluralism of approaches seer^s both v^arranted and 

necessary. Hov.'ever, v/ith the exception of [Moriconi 1977],. our work appears to be the only 
project which directly confronts the issue of incremental and evolutionary design of large 
software systems. 

In contrast to automatic programming and thernost ambitious high level languages, the design 
aid approach allows an important simiplification, namely that the computer need not be an expert 
in questions .of efficiency. If languages, comipilers, and automatic programming systems are to 
raise the level of abstraction of programming significantly, thereby hiding efficiency 
considerations, then they themselves must possess an expertise in efficient implementation 
resonably close to that of a competent programmer. Otherwise, they will not be used. A design 
aid system, in contrast, can provide significant assistance with virtually no understanding of 
efficiency at all. Furthermore, as techniques for reasoning about efficiency are developed they 
can be added to the system. There is alv/ays the escape hatch that the programmer can modify 
automatically generated code without losing the benefits of the design aid. Thus our approach 
allov/s a smooth transition from a passive assistant to a more automatic system. 

We also set a more modest research goal in comparison to program verification. We do not 
seek to gusraniee the correctness of a large softv/are system, a task we feel is very much harder 
than what current technology can manage. We set instead an intermediate goal of understanding 
the structure of the system and using this as a guide to bookkeeping and checking during design 
and modification. We expect that as our technology for automatically deducing the logical 
i^^-^ structure of programs progresses it will find application in the area of automatic verification. This 

should eventually make it possible to construct verifications (perhaps even for large systems) 
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which are more intelligibly structured than presently is the case. 
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